Follow-up PR: The signature for a hook is getting pretty unwieldy. The component_id was already an infrequently used parameter (IMO), and I imagine users ignoring caller (even if they shouldn't!). It might be worth refactoring entity, component_id, and caller into a Context struct. I've omitted world from that context since it's the only one out of these 4 that a user will mutate, so keeping it separate will avoid some partial-mutable-borow pains.

Follow-up PR: I think this pattern is pretty annoying to deal with. It's verbose and off-putting (IMO). I think we should investigate if obfuscating this behind a Context type which internally contains this feature gate is easier to use without sacrificing performance.

As much as I'm a no_std advocate, another alternative could be to use thread-local storage to manage this information without explicitly passing it as a function argument.

Would it make sense to use MaybeLocation instead of Option<&Location>? That would make it clear that the value is always present when the feature flag is enabled, and is never present when it's disabled.

That could be discussed in a follow-up, though! Really, I'd like to use something like that everywhere so that we don't need cfgs everywhere and I don't get CI failures because I forgot to build with the feature toggled. But I think that's more controversial so we shouldn't block this PR on that discussion.

I plan to coalesce the entity, component id and caller arguments into a single struct in a followup PR as suggested by bushRAT, which will have the same effect :)